Experimental BBS Explossion 3/Experimental BBS Explossion III.iso/gus/digestv5.zip/V5N14.TXT

Text File | 1993-08-16 | 13KB | 303 lines

Ultrasound Daily Digest     Sun Aug 15 00:07     Volume 5: Issue  14

Today's Topics:
                    About playmidi and 808 patches
                      Could it be my disks.....
                     Custom patches, banks, etc.
                        Efficiency in Patches
                         MIDIMON doesn't work
                   Patch suggestion: guitar chords.
                       Power Chords Controllers
The new sound card (what's REAL and what ISN't!) .... Sorry for wrong informatio

Standard Info:
    - Meta-info about the GUS can be found at the end of the Digest.
    - Before you ask a question, please READ THE FAQ.

----------------------------------------------------------------------

Date: Sat, 14 Aug 1993 21:52:43 -0400 (EDT)
From: [e-mail] (Francois Dion)
Subject: About playmidi and 808 patches
Message-ID: <[e-mail]>

For playmidi to work correctly with the TR 808 patches i made, you have to
include them in the cfg in this way:

for example you want to put the 808kick1 in perc position 34:

      34 ultrasnd\midi\808kick1

This is because the playmidi parser is broken (or sscanf flaky...). You could
also use a separate directory for custom patches:

      34 ultrasnd\custom\808kick1

So this should fix the problem. BTW, when you want to distribute any of my
patches with your midi file, please contact me. Basically i dont think it's
a good idea, cause it makes big files and defeat the purpose of the small
midi files. However, if you really need to distribute them along for some
reason, contact me and i'll arrange something.

Last, if someone wants a challenge, try to do 808 State's Cobra Bora song...
with the upcoming patches it should be feasible (combined with the 808 drums).

Ciao,
--
Francois Dion
    '  _   _   _
 CISM (_) (_)  _) FM       Montreal , Canada       Email: [e-mail]
      (_)  / . _)             10000 Watts          Telephone no: [phone]
_______________________________________________________________________________
Audio-C-DJ-Fractals-Future-Label-Multimedia-Music-Radio-Rave-Video-VR-Volvo-...

------------------------------

Date: Sat, 14 Aug 1993 23:25:42 +1000 (EST)
From: Michael Daniel <[e-mail]>
Subject: Could it be my disks.....
Message-ID: <[e-mail]>

Guess what!, I just recieved a bit of paper in the mail saing that there
was a parcel waiting for me at the post office...  Could i tbe my long
awaited upgrade disks..  I certainly hope so!! (it's either those or a
parcel asking us why we didn't enter Rally Australia again this year...)

    anticipating even happier GUSsing,   MPD 8-)

 --------------------------------------------------------------------------
|Michael Daniel| [e-mail] |Maths and Computer Science|
|  Swinburne University,  Eastern Campus,  Lilydale, Victoria, Australia. |
 --------------------------------------------------------------------------

------------------------------

Date: Sat, 14 Aug 93 2:29:16 PDT
From: Christopher Jon Wilkins <[e-mail]>
Subject: Custom patches, banks, etc.
Message-ID: <[e-mail]>

On the topic of how to organise custom patches ...

The current idea being thrown around is to create a `bank loading'
program to swap ultrasnd.ini files. This might be O.K. as a temporary
solution, but I think we should really seriously lobby Gravis to
modify the windows drivers instead.

The idea is this: implement midi sysex commands in the
Ultrasound driver to allow a dump request / bulk dump of
the 128 patch names. Also modify patch manager so that you can double click
on any patch number and it gives you a full list of possible patches in your
patch directory which you can use to replace the existing patch reference.

To put it another way, the 128 patch limit is quite arbitrary on the GUS.
It refers only to the number of different patches that can be obtained by
midi program change messages during playback of a file. This should have
nothing to do with the number of patches readily available on your GUS.

The reason a sysex implementation is most desirable is that no other
special GUS software would be necessary: all major sequencers already
support some form of automatic sysex loading with files (although now
I think about it I'm not sure it's part of the GM standard?). Otherwise
we're going to be stuck back in this ridiculous situation of loading
in a midi file into the sequencer and then loading in a matching
patch set file with another program. In other words it will be
the inconvenience of patch caching all over again.

In fact, if we pursue this line of getting the digest programmers to
knock up a `bank loader' we're going to be stuck with the following
procedure whenever we want to modify a file: open the sequencer program
and load in the file; open patch manager and again load in the file
(extract from file command); open the bank editor and AGAIN load in
the file (or its counterpart). In other words THREE loads whenever
you want to load in a file. This sort of procedure is beyond a joke
(although I admit it's better than the existing system of modifying
ultrasnd.ini !).

Sound sensible? Suggestions/modifications? If we can get an absolutely
clear idea of what it is we're after I'd say we've got a fair chance
of convincing Gravis to do it.

Gus musicians of the world unite!

Chris.

PS: BTW, anyone managed to make a GUS patch with a name that Patch
Manager recognises or is Patch Manager faulty? And why are my patches
supposedly 0K long?

------------------------------

Date: Sun, 15 Aug 1993 00:41:10 -0400 (EDT)
From: Phat H Tran <[e-mail]>
Subject: Efficiency in Patches
Message-ID: <[e-mail]>

It's great to see all those new patches people are making.  However, they
are usually so BIG!  Sometimes they need to be big, but often, better
use of looping, enveloping, and compromises in sampling rate and/or bit
resolution can yield a much smaller patch that sounds nearly as good as
the larger one.

Sampling rate.  We don't need samples recorded at 44.1kHz for many
instruments.  The GUS will just skip a lot of the sample points anyway
since most people use around 24-28 active voices.  Don't be afraid
to use lower sampling rates.  The GUS' interpolating capabilities
can fill in the missing points quite decently.

Looping.  Look for patterns in the waveform, capture one repeating
unit, and loop it to fill in the sustain.  The most complex waveforms
are during the attack, and the harmonics tend to stabilize rather
quickly.  Sometimes bidirectional looping can reduce the size of the
looped region by a half.  Remember to discard all the wave data a few
bytes after the end of the loop.  (It's safer to leave a few valid
sample points after the end of the loop so that the GF1 has something
to use for the interpolation if the voice lands fractionally outside
the loop.  I don't know if a voice is ever allowed to go past the
loop points before wrapping around or switching direction, but I'd
leave a buffer zone, just in case.)

Envelopes.  Remember to use the enveloping and AM/FM features instead
of sampling an entire note complete with sustain and decay.

With a max of just 1 Meg, and a hardware limit of 256k for 16-bit
samples, we should try to make our patches as compact as possible.

Phat.

------------------------------

Date: Sat, 14 Aug 1993 20:45:40 +0000
From: Clarke Brunt <[e-mail]>
Subject: Re: MIDIMON doesn't work
Message-ID: <[e-mail]>

[e-mail] writes...

> midim201.zip, midimon.exe. When I try to launch this executable
> under windows very little happens, the egg-timer is>
> instantaneously visible and then the application disappears,
> normal service is resumed (so to speak). Is there something
> environmental that I have forgotten to establish? The author
> provides usmail and compuserve addresses (but no source :-) but
> I am overcome with lazyness and wondered if the list at large
> has had similar trouble.

This is what I found as well, and I think someone else on the
Digest did too. I emailed the author, but he had no suggestions
as to what was wrong. He did not feel that he could upload the
source code, as it was largely from MicroSoft's SDK. I know that
some of these programs are said to require vbrun...dll (the
visual basic run-time library) but I'm pretty sure that this one
doesn't. It does use two other DLLs, but we've got them in the
same directory as the .exe so should be OK.

Any suggestions anyone?

------------------------------

Date: Sun, 15 Aug 1993 01:39:35 -0400 (EDT)
From: Phat H Tran <[e-mail]>
Subject: Patch suggestion: guitar chords.
Message-ID: <Pine.3.05.9308150135.A8982-9100000@sciborg>

To all those out there working on patches, do you think you could come up
with some guitar chords?  Building up chords from individual notes just
does not produce realistic results, at least on the GUS, as the resonance
of the strings is lacking.  I think great .mids can be made with the
appropriate set of sampled chords.

Phat.

------------------------------

Date: 14 Aug 93 08:21:40 EDT
From: "Eric Bell, Howling Dog Systems" <[e-mail]>
Subject: Power Chords Controllers
Message-ID: <[e-mail]>

> [e-mail]
>
> I have tried using the controller window to send a stream of increasing values
> on controller 10, but I get nothing for my efforts. Any suggestions/comments/
> clues?
> P.S. I have no keyboard or I would use CakeWalk.

> The controls are not for doing continuous controller stuff. They are for
> sending reverb or chorus levels, or pan info, or patch changes etc. as
> opposed to pitch bend.

> Get Power Chords Pro - it has a keyboard on-screen, and you can record
> what you play on the fret-board or keyboard to any type of rhythm - melody
> drums, whatever.

> Eric

------------------------------

Date: Sat, 14 Aug 93 00:15:27 GMT
From: [e-mail] (Thomas van Kuipers)
Subject: The new sound card (what's REAL and what ISN't!) .... Sorry for wrong informatio
Message-ID: <[e-mail]>

Hi,

I saw your reply about Diamonds Sonic Sound. I'm the guy who
placed the artikel.

A Friend of Mine has bought a card (SOLD his GUS) for about
$250. I ALREADY found out that there wasn't RAM on it, BUT IT
HAS CACHE RAM (64kB) and has the rom modules. Further it has
an upgradubility to 8 mb rom (the dealer said) for about $120.
Further It has SCSI-2 on board, it's totally 16-bit (recording
and playing) and has HARDWARE comp. Soundblaster / adlib on it.
So you have for about $50 more the two daugterboards
(scsi/16-bit) AND hardware SB comp. (Oke i'll know dan that
the aria isn't comp with gus totally)
I know a lot about computers and i like MY GUS very much, but
after that it is still a good priced card with an high
performance and it DOES sound better than a GUS, you know.

Oke, Guys, you musn't think i advice EVERYONE to buy it, but
it is rather a push for GRAVIS to come up with something,
perferably a GUS with 8 MB RAM and 16-bit + scsi in one
(hopefully for onely $250 or so).

Sorry for the misunderstanding about the possiblities i
placed, but it came from my friend, because he had only an
sort fax of it (and i posted that information). After 2 days i
saw it and i know now that it hasn't any ram on it (shame).
Oh yeah it had NOTHING to do with the post in that NEWSGROUP,
because i don't read that stuff yet .........

Bye,

Thomas van Kuipers
Email: [e-mail]

------------------------------

End of Ultrasound Daily Digest V5 #14
*************************************

To post to tomorrow's digest:                        <[e-mail]>
To (un)subscribe or get help:                <[e-mail]>
To contact a human (last resort):              <[e-mail]>

FTP sites:                archive.epas.utoronto.ca         pub/pc/ultrasound
                          wuarchive.wustl.edu       systems/msdos/ultrasound
                          archive.orst.edu               pub/packages/gravis
FTP mail server:          [e-mail]

Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <[e-mail]> for info about other GUS
        related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)